The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
1. Overview
Traffic over modem communication networks can be quite heavy, with large numbers of communicating entities sharing the network's finite available bandwidth resources. Some entities generate network traffic that has importance, inherent or ascribed, that may typically be greater than other traffic.
Moreover, some kinds of network traffic from any of a variety of sources may be more sensitive to delay. For instance, real time voice communications, videoconferencing and interactive traffic can be especially sensitive to latency, jitter and related effects, in contrast with traffic of a more transactional nature and/or otherwise less sensitive to delay. The operation of modem networks is managed to minimize delay to traffic that may be delay sensitive and/or from high priority sources.
To minimize delay for traffic with heightened sensitivity to delay and traffic generated by high priority sources, networks implement Quality of Service (QoS) capabilities. QoS provides priority to delay-sensitive and high priority network traffic with techniques that can include dedicated or otherwise guaranteed bandwidth, controlled latency and jitter, and minimizing loss characteristics such preventing dropping of packets therefrom.
QoS is achieved by using networking functions to examine the Internet Protocol (IP) frames in packet headers. Differentiated Services Code Point (DSCP) bits therein are classified and marked to denote the QoS level to which the message is entitled and thus, the priority with which its packets are handled by the network elements, including devices such as routers and switches.
QoS thus provides a guaranteed minimal level of service in the form of traffic prioritization and preferential forwarding. Web services are essentially multiple Web-based applications that dynamically interact with each other with open standards.
Application messages convey a priority that they hold from an applications based perspective. However, the information that conveys applications based message priority may only rarely align optimally with network QoS classification and marking. To provide QoS based message handling, network elements use combinations of source and destination IP addresses and/or Layer 4 parameters to prioritize message traffic based on the classification and relative packet priority based on the DSCP markings.
Message based applications, in contrast, abstract Remote-Procedure Call (RPC) interfaces within the body of a particular message. Message based applications use Hyper Text Transfer Protocol (HTTP) and/or HTTP-Secure (HTTPS), TCP or Java Messaging Service (JMS) to transport messages between systems. For instance, HTTP (port 80) is used as a common transport protocol for exchanging messages between systems that may be accessing applications such as SAP, Siebel, and the like.
Other information that is embedded in an application message may pertain to a message's importance in relation to other messages. Such embedded information can include, for example, the value of an order and/or the identity of a message's source. However, as message based applications abstract application RPCs within a common transport “tunnel,” conventional network devices cannot determine the relative importance of the packet content by inspecting the TCP port.
Conventional network devices are thus unable to apply DSCP markings to appropriately queue packets of an application message. Also, while keywords within a message, such as ‘*/trade’ and ‘*/quote’ within a Uniform Resource Locator (URL), may be pertinent to message priority, the URL neither identifies the application being invoked nor conveys the relative importance of the message content. Further, content and context encryption can constrain TCP based priority classification with string matching.
Conventional networking approaches use hardware and software to provide network QoS. Further, numerous modem applications may themselves possess the ability to support message level priority, which enables them to act on messages deemed relatively more critical than others prior to handling the less critical messages. However, the application based priorities neither set nor influence network QoS values and the network elements do not set or directly affect application priority.
The lack of application influence on the network elements in relation to QoS and the lack of network influence in relation to application priority can be problematic.
2. Example Background Illustrations
In a business-to-business environment, applications executing on computers commonly communicate with other applications that execute on other computers. For example, an application “A” executing on a computer “X” might send, to an application “B” executing on a computer “Y,” a message that indicates the substance of a purchase order.
Computer “X” might be remote from computer “Y.” In order for computer “X” to send the message to computer “Y,” computer “X” might send the message through a computer network such as a local area network (LAN), a wide-area network (WAN), or an inter-network such as the Internet. In order to transmit the message through such a network, computer “X” might use a suite of communication protocols. For example, computer “X” might use a network layer protocol such as Internet Protocol (IP) in conjunction with a transport layer protocol such as Transport Control Protocol (TCP) to transmit the message.
Assuming that the message is transmitted using TCP, the message is encapsulated into one or more data packets; separate portions of the same message may be sent in separate packets. Continuing the above example, computer “X” sends the data packets through the network toward computer “Y.” One or more network elements intermediate to computer “X” and computer “Y” may receive the packets, determine a next “hop” for the packets, and send the packets towards computer “Y.”
For example, a router “U” might receive the packets from computer “X” and determine, based on the packets being destined for computer “Y,” that the packets should be forwarded to another router “V” (the next “hop” on the route). Router “V” might receive the packets from router “U” and send the packets on to computer “Y.” At computer “Y,” the contents of the packets may be extracted and reassembled to form the original message, which may be provided to application “B.” Applications “A” and “B” may remain oblivious to the fact that the packets were routed through routers “U” and “V.” Indeed, separate packets may take different routes through the network.
A message may be transmitted using any of several application layer protocols in conjunction with the network layer and transport layer protocols discussed above. For example, application “A” may specify that computer “X” is to send a message using Hypertext Transfer Protocol (HTTP). Accordingly, computer “X” may add HTTP-specific headers to the front of the message before encapsulating the message into TCP packets as described above. If application “B” is configured to receive messages according to HTTP, then computer “Y” may use the HTTP-specific headers to handle the message.
In addition to all of the above, a message may be structured according to any of several message formats. A message format generally indicates the structure of a message. For example, if a purchase order comprises an address and a delivery date, the address and delivery date may be distinguished from each other within the message using message format-specific mechanisms. For example, application “A” may indicate the structure of a purchase order using Extensible Markup Language (XML). Using XML as the message format, the address might be enclosed within “<address>” and “</address>” tags, and the delivery date might be enclosed within “<delivery-date>” and “</delivery-date>” tags. If application “B” is configured to interpret messages in XML, then application “B” may use the tags in order to determine which part of the message contains the address and which part of the message contains the delivery date.
A web browser (“client”) might access content that is stored on remote server by sending a request to the remote server's Universal Resource Locator (URL) and receiving the content in response. Web sites associated with very popular URLs receive an extremely large volume of such requests from separate clients. In order to handle such a large volume of requests, these web sites sometimes make use of a proxy device that initially receives requests and distributes the requests, according to some scheme, among multiple servers.
One such scheme attempts to distribute requests relatively evenly among servers that are connected to the proxy device. A proxy device employing this scheme is commonly called a “load balancer.” When successful, a load balancer helps to ensure that no single server in a server “farm” becomes inundated with requests.
When a proxy device receives a request from a client, the proxy device determines to which server, of many servers, the request should be directed. For example, a request might be associated with a session that is associated with a particular server. In that case, the proxy device might need to send the request to the particular server with which the session is associated.
If the server to which the proxy device sent the request is not able to service the request, one of several scenarios may occur. In one scenario, the server might send no response whatsoever. Under this scenario, after a specified amount of time has passed since the client sent the request without receiving a corresponding response, the client may determine that a “timeout” event has occurred. The client may take a specified action that is associated with the timeout event, such as notifying a user that a response to the request could not be obtained.
In another scenario, the server might send an HTTP-specific response that indicates that the server is not able to service the request. For example, the server might send a “500” code in an HTTP header. The client may receive the HTTP-specific response and take a specified action that is associated with the HTTP-specific response, such as notifying a user that the request could not be serviced.
Under either scenario, the only recourse left to the client is to resend the request. However, when the client resends the request, the resending wastes both network bandwidth and the client's processing resources. Furthermore, although HTTP provides codes whereby a server can notify a client, in a protocol header, that the server is unable to service a request, sometimes clients and servers communicate using protocols other than HTTP. Some of these other protocols do not have such built-in notification mechanisms.
A less wasteful, more productive, and more widely applicable technique for managing server failure, or the inability of a server to service a request, is needed.
Present approaches in data processing are inadequate with respect to network topology visibility, transmission of verbose XML documents, processing network identities of users, validating XML schemas, load balancing, and processing database application messages. Improved approaches in these areas are needed.
Further, conventional QoS priorities are relatively static. However, this may be inconvenient and/or seem inflexible in application aware networking, where the roles attributed to various message senders and other users may be dynamic over time, situation and circumstance.